Currently, there are two ways to run appliance functionality on a system while keeping the primary operating system (OS) environment in a preserved state. Each of these has their disadvantages. In a first way, a user can invoke the appliance functionality within the primary OS. The primary OS, being aware of the special needs of the appliance does the appropriate changes to the software and hardware environment to accommodate this. There are several disadvantages to this. One disadvantage is that appliance developers may want to use an OS that is tailored for their application, e.g. developers may want easy portability from a hard appliance model. Another disadvantage is that appliance functionality would be subject to vulnerabilities and instability of primary OS. One additional disadvantage is that appliance mal-functions can damage the primary OS environment. A further disadvantage is that specific requirements of the Appliance such as power optimization (e.g., extended media play), and real-time response will most likely be not met by a general purpose primary OS.
In a second way, the primary OS environment is preserved in a hibernation state and the system is switched to a different mode. This is currently used by some OEMs for hosting single functions such as DVD playback. This puts the primary OS environment into a saved state on the hard disk. This has a disadvantage that a switch to the appliance mode takes an undesirably long time.
This can take 20 seconds, depending on the system memory usage by primary OS. This makes frequent mode switches cumbersome, thereby impeding various functions such a usage of a secure browser.